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1. INTRODUCTION 

The purpose of this report is to present an overview 
of a software development system built by Science Applications 
Inc. , of Huntsville, Alabama, under the direction of the 
Data Systems Laboratory of NASA, Marshall Space Flight Center, 
The system, called the Software Specification and Evaluation 
System (SSES), was designed for the effective and efficient 
specification, implementation, and testing of computer software 
programs. The system as implemented will produce structured 
FORTRAN or ANSI FORTRAN programs, but the principles upon 
which SSES is designed allow it to be easily adapted to other 
high order languages. 



2. CORRELATION OF SCOPE OF WORK TASKS 
TO SECTIONS OF THE FINAL REPORT 


This final report describes the results of the work 
performed in fulfilling the scope of work tasks for contract 
NAS8“31554. These tasks were (A) to complete the detailed 
design of the Software Specification and Evaluation System 
(SSES), and (B) to implement the critical SSES components. 

In fulfillment of Task A, an overview of SSES is presented 
(Section 3.1 of this report), along with an example which 
depicts the use of SSES in the development of reliable software 
(Appendix A of the Final Report). 

The remainder of Section 3 of the Final Report re- 
flects the work performed in accordance with the specifications 
of Task B. Most of the SSES components developed under Task 
B resulted in new software tools for which many forms of tech- 
nical documentation such as design documents, user's manuals, 
operation guides, listings, and flowcharts were produced. The 
chart appearing in Figure 2-1 contains a summary of the docu- 
mentation delivered for each new software tool as well as for 
the Software Requirements Methodology and the Data Base Veri- 
fier. Since this documentation is very detailed, the sections 
of this final report pertaining to the new or modified soft- 
ware components present only overviews of the work performed 
in each area. A summary of the Final Report sections and 
their relat ionsiA^p to the scope of work tasks is presented in 
Figure 2-2. 


Figure 2-1, Technical Documentation for SSES 
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3 . SSES METHODOLOGY 


3.1 SOFTWARE SPECIFICATION AND EVALUATiO’J SYSTEM (SSES) 

DESIGN OVERVIEW 

(Task A: SSES Design Completion) 

Early in 1975, SAI and NASA Jointly began a software R&D 
effort to develop a methodology which could reduce the effort 
expended in a typical software test and verification activity 
without sacrificing confidence in performance, thus improving 
the cost effectiveness of the overall software development. The 
Software Specification and Evaluation System (SSES) has been 
developed to achieve these goals. The system includes special- 
purpose languages and automatic requirements/code verification 
and validation tools designed to improve the quality assurance, 
traceability, testability and maintainability of the final 
•software product. 

The SSES comprises a set of integrated components based 
on the following software development phases: 

® For the Requirements/ Specification phase, a 
requirements methodology was developed to 
insure the integrity and feasibility of the 
software requirements. This methodology in- 
cludes a prescription for the necessary content 
of the software requirements specification. 

Also, there is a formal Software Specification 
Language (SSL). This language is used to 
formally describe the overall software system 
(or functional) structure and, thereby provide 
a firm foundation for the software design 
process. SSL automatically provides for the 
traceability of requirements and checks element 
interconnection consistency. 

o For the Coding phase, language disciplines 

for the promotion of reliable software have been 
identified and incorporated into a high-level, 
structured FORTRAN language. This language 
is translated to ANSI 3.9 FORTRAN through 
a preprocessor. Further work in this area 
includes the formulation of a complete pro- 
gramming methodology to alleviate questionable 
coding practices and, thus, increase reliability 
and flexibility. 



For the Verification and Validation phase, there 
is a Static Code Analyzer, a Data Base Verifier 
a Dynamic Analyzer, and an Automatic Structural 
Test Case Generator. The Static Code Analyzer is 
used to enforce technical coding standards and to 
document pertinent program information tc be used 
during other V&V activities. The Data Ba.se 
Verifier is used to analyze the program's accessing 
specifications and construct tables which describe 
the stored data base. (This tool exists in design 
only and will not be implemented until FORTRAN 
CODASYL standards have been set.) The dynamic anal- 
yzer is used to dynamically analyze the software 
system's execution characteristics, providing execu- 
tion path trace and variable trace information. In 
order to provide adequate test case coverage, an 
automatic test case generator is used to test the 
final software product. 


The application of the SSES components, the methodologies, reliabil- 
ity disciplines, and software tools, to the software development 
cycle are pictorially presented in Figure 3-1. 
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Figure 3-1. Augmented Development Cycle 










3.2 SOFTWARE REQUIREMENTS METHODOLOGY 

(Task Bl: Software Requirements Methodology Design) 

In the area of software requirements, a method of 
stating requirements which enhances clarity, consistency, com- 
pleteness, traceability, and testability had to be defined. 

These requirement expressions represent all the relationships 
between the input and output and between the to-be-produced 
product and its environment without unnecessarily limiting the 
possible configurations of that product. Using SPACELAB soft- 
ware, an initial consideration of the approach that was devel- 
oped for NASA to use in developing software requirements speci- 
fication documents is presented in the following paragraphs. 

As depicted in Figure 3-2, the software development pro- 
cess consists of activities, documents, and reviews. In order for 
the reviews to be maximally effective, the software and supporting- 
documentation needs to be clearly expressed and sequentially 
traceable. In particular, with regard to the design requirements 
review (DRR), the software requirements specifications should be a 
function of (and must bridge the gap betv,feen) the prior activity — 
system design (not depicted) and the succeeding activity — prelim- 
inary software design. Consequently, the software requirements 
specification, whatever its particular format, should contain the 
information listed in Figure 3-3. 

The method in which such information is expressed should 
probably be project or personnel dependent. Some factors affect- 
ing the choice of method are: 

9 training and background of requirements developers 
9 desired breadth of requirements visibility 

• generic type of software 

e allocated finances and other resources 

One specific format (for SPACELAB software) will be sug- 
gested in the Software Requirements Design Specifications to be 
deJivered as part of the task vrark. The design document will 
depict the key aspects of the Software Requirements Methodology, 
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Of all the software development phases, requirements def- 
inition is undoubtedly the most important. The kind of inform- 
ation depicted in Figure 3-4 illustrates the quality and cost ad- 
vantage that can be gained through a careful execution of this 
initial stage of software development. 
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; 3.3 SOFTWARE SPECIFICATION LANGUAGE 

(Task Bl; Software Specification Language Imple- 
mentation) 

The purpose of SSL (Software Specification Language) 
is to aid in the process of defining systems and modules in 
order to alleviate software interface errors and improve re- 
quirements/design traceability. A formal description of the 
syntax and semantics exists which has enabled the construction 
of an automatic translator. The translator makes a series of 
nontrivial consistency checks based primarily on a system flow 
model that is assumed to exist apart from the SSL description 
and which originated in the software requirements specification. 
The essence of the flow model is checked implicitly by several 
features within the language. 

3.3.1 Elements of the SSL Computation Model 

SSL is a machinable design analysis tool with a 
formal syntax and semantic description. It does not impose 
artificial restrictions on data flow or software architecture 
but does insist that both conform to a separately developed 
system flow model. This affords the opportunity to perform 
extensive nontrivial consistency verification and develop a 
document that aids communication of design intentions and testing 
criteria to subsequent phases. The basic elements underlying 
an SSL description are data structures , modules , levels of 
abstraction , and requirements . 

Anyone with an understanding of data declarations in such 
procedural languages as ALGOL and PL/ I can easily grasp 
the concepts of variable and data structure in SSL. The lan- 
guage provides a small number of basic data structures. 

Tt also provides a small number of basic data types for 
which there is a direct implementation or trivial extension of 
a direct implementation on most hardware. These types may be 
used to affix attributes to simple variables or combined to 
dpsctribe composite variables. 





Generally, a module is understood to be a program unit 
that can be understood independently of the rest of the system. 
Examples are COBOL paragraphs, ALGOL procedures, and FORTRAN sub- 
routines. Modules are further combined into higher entities call- 
ed levels of abstraction under the interconnection operation. 

Levels of abstraction are sets of modules, embedded with- 
in a larger system, having several distinct properties; 

PI. A level of abstraction is a set of modules which 
inay share global data (and perhaps hardware 
features) among themselves, but not with modules 
outside the set. In any case, a subjective com- 
monality of function or purpose binds all modules 
within a set. 

P2. A subset of the modules with property PI (called 
entry or external modules) can be referenced 
only from modules in other levels. 

P3. There is a unidirectional dependence among the 
sets (i.e. a higher level may reference an 
entry module of a lower level but not vice 
versa) . 

In SSL, there are four components to a requirement: 
input, output, transduction, and constraint. Input and output 
are named variables corresponding to system level stimuli 
and responses. Constraints are simply named-entities attached 
as attributes to various objects within a described system. Their 
higher or conceptual meaning is not directly representable 
in SSL. Transductions are also named-entities attached as 
attributes to objects, but their purpose is to capture, via a 
partial ordering, the flow model underlying the module decom- 
position. 

3.3.2 The Language 

Systems described in SSL are partitioned into one or 
more subsystems where each subsystem corresponds to a level of 
abstraction. Within each subsystem one or more modules are 
described nonprocedurally . Module description statements per- 
mit module connections and data flow to be depicted in a 
variety of ways, subject to the restraints imposed by the 
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underlying flow model. The flow model (i.e., requirements) and 
data structures are defined in a subsystem preamble. A partial 
ordering of transductions is specified in the preamble. 

Modules are the focal point of an SSL description of a 
decomposition. Information represented about modules includes 
input variables, output variables, called modules, and transduct- 
ion attributes which guard all interconnections. The general form 
of a module description in SSL is: 


MODULE 

ENTRY 


(module name} [(local variable list)]; 


ASSUMES 

SATISFIES 


FULFILLS 


ACCESSES 


USES 


CREATES 


MODIFIES 


EXECUTES 


. {assertion list}; 

I 

{transduction and constraint listi; 

{environment list}; 

{variable or component list); 

{variable list} USING {variable or 

component list}; 
{variable or component list) 

USING { variable or component list); 

ITERATIVELY ({module reference list}) 
CONDITIONALLY 


END MODULE; 


Transduction attributes play a role in limiting the ac- 
cess scope of global data accessed in the MODIFY and USE state- 
ments or USING clause. For example, each transduction attribute 
of the module must be either the same as some transduction attrib- 
ute of the variable or a successor (in the partial ordering sense) 
of .some attribute of the variable. The effect of this rule is to 
limit the use of a variable to sper2ific subnetworks. Similarly, 
in order for one module to reference a second module within the 
same subsystem, the first module must have transduction attributes 
that imply at least one attribute of the second module. This 
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insures that the module ordering will generally correspond to the 
transduction ordering which, in turn, corresponds to some under- 
lying flow model. Yet, the rule is not excessively constraining. 
The produced module network is seldom a simple restatement of the 
system level flowchart. The preliminary designer has considerable 
freedom within which to decompose the flow processes. 
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3.4 STRUCTURED FORTRAN PREPROCESSOR 

(Task B2: High Level Language Disciplines 

Determination and Structured Preprocessor Selection) 

The goal of consistently producing reliable software 
dictates certain criteria for the structure of the program 
language employed. A list of criteria which an ideal programming 
language should satisfy was derived from studying programming 
languages that promote reliable code implementation. These 
criteria are as follows: 

« The language should follow naturally 
from a top down approach and should 
be able to reflect the problem at hand, 

• The language promotes a sequential imple- 
mentation , 

• Control structures should be explicitly 
clear and should be kept to a minimum. 

9 The language should exhibit the same 

syntax structure for semantically similar 
constructs . 

® The language should allow indentation 

and a type of modularization that clearly 
defines the boundary of each module 
and allows each module to be clearly 
and completely locally understood. 

9 The language should have meaningful 
reserved words . 

• The language should allow the programmer 
to write often used constructs with a 
minimum of detail. 

« The language should offer a nonrestrictive 
placement of commenLS which facilitates 
trouble-free usage. 

• Side effect changes of data should be 
made explicit and restricted to a minimum. 

9 Data types and other information crucial to 
correct execution should be explicitly 
specified preferably in several different ways. 
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• The language should have a context-free 
syntax. 

• The language should he amenable to automatic 
code analysis. 

• Machine overhead of often used constructs 
should be kept to a minimum. 

Attempting to find a language that satisfied the above 
criteria while simultaneously acknowledging NASA's wide use of 
FORTRAN influenced us to consider a structured FORTRAN preproces- 
sor as a language vehicle. Existing structured preprocessors were 
evaluated to determine which ones incorporated a large number of 
the criteria listed above. A preprocessor developed by the U.S. 
Army Missile Command at Redstone Arsenal was selected as the basis 
of our work. It featured three primary control structures for 
structured programming: the concatenation capability, the IF-THEN 

-OR IF-ELSE construct, and the DO WHILF construct. The FOR and 
lEST CASE constructs were added for user convenience. The prepro- 
cessor accepts structured FORTRAN source statements as input, and 
generates corresponding ANSI 3.9 FORTRAN statements. These gener- 
Lted source statements can then be used as input to an ANSI 
FORTRAN complier. Moreover, the structured FORTRAN preprocessor 
provides for automatic identification of nesting levels. 

■ In addition, the original preprocessor as well as all 

subsequent modifications were designed with transportability as 
a priority. To date, the structured FORTRAN preprocessor has 
been readily implemented on the IBM 360 and 370, CDC 6600, 

■UNIVAC 1108, PDP 10 and 11, and the SEL computing systems. 
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:j.5 static analyzer 

(Task B3: Static Code Analyzer Implementation) 

After the desired software modules have been coded and 
compiled, the next step in producing reliable software is to 
verify and validate the code using software tools. From the SSES 
ri^portoire, the logical component to use first is the static 
code analyzer. The static code analyzer accepts ANSI FORTRAN 
source code as input, evaluates the code according to intramodule 
ami inl"nn)(lule c.onslderat ions , and produces appropriate output 
whii-h idonttfies parts of the code which are likely candidates 
jlnr inconsistencies and errors. Proper technical coding standards, 
good programming style, and appropriate program structure are all 
chocked during the evaluation of the source code. To satisfy the 
task requirements in the area of static analysis, the following 
culpabilities were added to the NASA static analyzer, FACES: 

® EQUIVALENCE and EXTERNAL statements are flagged. 

® Unlabeled COMMONS are flagged. 

ffi DIMENSION statement and variable which contain 
an adjustable (variable) dimension are flagged. 

e Arithmetic IFs are flagged. 

0 Targets of branches should not be other branches, 
especially single GO TOs. 

® Occurrences of error-prone FORTRAN statements 
such as ASSIGN statement, assigned GO TO, and 
PAUSE are flagged. 

Th(\sti m^w features represent a significant increase in the 
ovf^ralt i.'l' feet i veness of the NASA static analyzer. 
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3.6 DATA BASE VERIFIER 

(Task B3: Data Base Analysis Tool Design) 

The approach to data base verification was based on 
CODASYL's (Conference of Data Systems Language) view of a data 
base management system. The CODASYL organization has been engaged 
in the development of language standards for describing extensions 
to existing high level languages (e.g. COBOL and FORTRAN) which 
will allow access and operation on the data base components as 
well as describe the part of a data base which resides on perman- 
ent storage. According to CODASYL’s definition, a data base man- 
agement system is a system which manages and maintains data in a 
non-redundant structure for the purpose of being processed by one 
or more applications. In a data base management system, an appli- 
cations programmer writes a program in a higher order programming 
language such as FORTRAN or COBOL which has been augmented to 
incorporate Data Manipulation Language (DML) commands. The DML 
statements provide interfaces between application programs and 
d:ii ;i during execution. 

Our data base verification subsystem concentrates on 
th(' FORTRAN applications program written in ANSI FORTRAN which 
has been extended to include Data Manipulation Language (DML) 
commands. It accepts CODASYL FORTRAN Data Manipulation Language j 
source code as input, and statically analyzes the program. Data 
ba.se description tables are then constructed which describe 
the stored data base that the program accesses and manipulates. 
Finally, it prints a, report containing a summary of all the 
iniormation collected about the components and the structure of 
the stored data base. The user must then establish the con- 
sistency and validity of the stored data base within the 
Cramework of the program descriptions by cross referencing these 

l.ablo.R. I 
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3 . 7 DYNAMIC ANALYZER 

(Task B3; Dynamic Code Analyzer Implementation) 

Continuing the code verification and validation process 
using the SSES methodology, the next logical software tool to exe- 
cute would be the dynamic analyzer. The dynamic analyzer accepts 
either structured or ANSI FORTRAN source modules (or a combined 
stream of hoth types of modules) as input. The static analysis 
section of the dynamic analyzer recognizes all the necessary 
statement types, and sets up a program graph of the source code 
which emphasizes branch nodes. The program graph is constructed 
from the target program by assigning to each program statement 

! 

(line) a node on the graph and using the edges between these nodes 
to represent control flow of the program. A decision-to-decision i 
(DD) path is a path which begins and ends on a decision or branch 
node. The DD paths are important because they are used as indi- 
<;ators for inserting probes into the code. One probe is placed 
for each DD path in the program-graph. The instrumented source 
code is then written to a file which may be attached in the same 
computer run or a later one. After this file has been attached, 
compiled, and loaded (or link edited) with the Dynamic Analyzer 
run time package, the module is executed and run time statistics 
aro collected. When the execution is completed, the third com- 
ponent of the Dynamic Analyzer, the trace analysis package, reads 
and interprets the data collected in the previous step. A de- 
tailed module test report, including a node/stacement list, a DD | 
path analysis, and a monitored variable list along with a summary 
report of the effectiveness of module testing is produced. (A 
sample test report is presented in Appendix A. ) These reports ■ 
provide the author of the software a comprehensive dynamic anal- 
ysis of the software modules. The author can then determine by 
in.spection which areas of code are most critical- Since the test- 
ing coverage is documented, the author has a reference for any 
further testing of the software modules reg^.rdless of whether 
modifications are necessary. 
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3.8 STRUCTURAL TEST CASE GENERATOR 

(Task B3: Structural Test Case Generator Implementation) 

The structural test case generator assists in the gener- 
ation of test data sets that will exercise desired segments of 
c()de. It accepts structured FORTRAN code as input and performs 
sf?veral different functions for the user. First of all, it deter- 
mines the total number of execution paths from entrance to exit in 
the module, based on some assumptions concerning the looping struo 
Lure, Other functions of the test case generator are determin- 
ations of minimum and maximum coverage tests and a measure of 
probable testing effectiveness for these two testing alternatives, 
^or the first calculation, the minimum number of distinct test 
cases which must be produced to meet the testing goal of covering 
each DD path in at least one of the tests is computed. This set 
of test cases represents the "best case" situation for testing 
purposes. In the next calculation, the structural test case 
generator determines the number of distinct test cases required 
to satisfy the execution of all DD paths which represents a 
"worst case" situation. Dividing these minimum and maximum 
number of tests by the number of execution paths yields a minimum 
and maximum (probable) testing confidence measure, respectively. 

In effect, this measure reflects how thoroughly, in terms of 
Lotal possible execution paths, the program would be tested by 
using the minimum or maximum number to achieve DDP coverage. 
Re.sultant low values indicate that a high level of confidence 
can be placed in program behavior based on the DD path coverage 
tests . 

I The remaining test case generator function is a potential 

I 

ipath .selection which takes into account the previously calculated 
measurements. The cover selector portion of the output report 
pre.soribes an ordered selection of DD paths in a sequence of steps, 
which will number between the minimal to maximal values, to be 
executed in order to achieve complete DD path coverage. With the 
output generated from this automatic code analysis tool, a user 
can make a quick, more productive selection of paths for test data 
generation . 
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'I.O SSES BENEFITS AND UTILIflATION EXPERIENCE' 

All of the SSES components previously described except 
the data base verifier have been implemented. During implemen- 
tation, productivity figures were kept on the Dynamic Analyzer and 
the Software Specification Language Preprocessor which were devel- 
oped using as much of SSES as was available. Table 1-1 contains 
these figures and their comparisons with industry standard pro- 
ductivity estimates. The fact that personnel training and famil- 
iarity with the SSES components is not reflected in the figures 
must be taken into account when viewing Table 1-1. The produc- 
tivity rates for the SSES component development for which many 
programmer interactions occurred show a 2 to 1 benefit ratio in 
comparison with the Aron figures. This increase in productivity 
represented a corresponding cost reduction in the development of 
reliable software which was one of the original objectives of 
SSES. 

Experience has shown the Software Specification Language 
to be a useful tool in evaluating the early design efforts prior 
to further expenditure of resources. The primary contribution of 
the language is an existence proof that higher order verification 
is possible. This is accomplished by two basic semantic rules 
that relate the decomposition to a system flow model without de- 
manding the system architecture be a simple restatement oi the 
■node!. Simultaneously, the system encourages use of modularity, 
high level data types, and levels of abstraction. 

The Structured FORTRAN Preprocessor was used in the devel- 
:^pment of SSL, the Dynamic Analyzer, and the Structural Test Case 
fTonerator. It promoted "built-in" software reliability by allow- 
ing the implementors to use structured programming, and its ease 
dC use simplified the coding of these software tools. 

The static analyzer FACES has been^ used for a portion of 
the shuttle structural testing data acquisition system. FACES was 
applied after the software had been debugged. Error conditions 
fvere detected in 6.5% of the source code analyzed, and one half of 
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1% of these errors were "fatal”. If FACES had been applied at the 
beginning of the debugging phase, the benefits would have been 
greater. 



Table 1-1. COMPARATIVE SOFTWARE PRODUCTIVITY RATES 


Aron Corbato SSES 

(Wo System (System (System 

Testing) Tested) Tested) 


Very Few Programmer Interactions 39 HOL Lines/ 

Man Day 


50 


Some 19 5 

Many 6 12 

Using SSL, Structured Preprocessor, FACES 


APPENDIX A 

SSES SOFTWARE DEVELOPMENT EXAMPLE 





APPENDIX A 


SSES SOFTWARE DEVELOPMENT EXAMPLE 


The following pages contain an example of a 
computer program developed by the NASA SSES 
Software Development System. The program is 
intended to solve the problem appearing on 
the next page. For this program we have 
written the following SSES documents and 
listings: The Software Requirements 

Specification, the Software Specification 
Language, the Structured Preprocessor Listing, 
the ANSI FORTRAN Listing, the Static Analyzer 
Listings, the Dynamic Analyzer Listings and 
the Structural Test Case Generator Listing, 
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PROBLEM 


"A program is required to process a stream of telegrams. 
This stream is available as a sequence of letters, digits and 
blanks on some device and can be transferred in sections of pre- 
determined size into a buffer where it is to be processed. The 
words in the telegram are separated by sequences of blanks and 
each telegram is delimited by the word '-ZZZZ'. The stream is 
terminated by the occurrence of the empty telegram, that is a 
telegram with no words. Each telegram is to be processed to 
determine the number of chargeable words and to check for occur- 
rences of overlength words. The words 'ZZZZ* and 'STOP' are not 
chargeable and words of more than twelve letters are considered 
overlength. The result of the processing is to be a neat listing 
or the telegrams, each accompanied by the word count and a message 
indicating the occurrence of an overlength word." 









SOFTWAHE REQUIREWEMT SPECIFICATION 

1. Name: Telegram Processing Program 

2. Purpose: See Previous Page 

3a. Inputs : character stream on a drum of fixed length records 

3b. Outputs: printed telegram with detailed changes 

4. External Interfaces: Drum, Printer 

5. Global Performance Requirements: Must run in 32K 

6. Global constraints: Must run on a PDP-8 

7. Functional Decomposition : j 

j see Following Sheets 

8. Transductions and Implications: ) 




Print 1 : Collect words into telegrams 

Print 2 : Print whole telegrams 

Print 3 i Print all telegram charges 

Collect 1: Collect characters into words 

Collect 2: Print cverlength word messages and physical 

record end of file messages 

Separate : Return next character in telegram file 

Read : Enter next physical record from drum into 

character buffer 

Collect 1, Collect 2 c print 1 
Read ^ Separate 







































USING SOFTWARE SPECIFJCATIOM LANGUAGE 


MODULES AND 
INTEftCONNECTIONS 
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MODULES AND 
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DESCRIPTION 





CORRECTION OF 

inconsistencies 


TO DETAILED DESIGN 


SOFTWARE SPECIFICATION LANGUAGE 


A semi -automated tool that assists in conversion 
from written requirements to computer code structure, 


Checks the consistency of the logical flow of data 
and computations sequence to generate the desired 
output for a given input . 


Provides requirements traceability. 
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Sample Table of Contents from an SSL Report 
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The subroutine GET-’WORD fiilfilTs the 
requirements transductions GOLLECT 1 
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Sample SSL Source Program 
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STRUCTURAL TEST CASE GENERATOR 


( Implemented) 


• COVER SELECTOR - To gauge the number of execution paths in the 

program and to select an optimal cover for 
testing purposes. 

• DDP CONDITION LINKER - To associate a series of decisions (in 

simplest form) with each execution path. 

• NEXT TEST r- To select the best next path for test case 

generation based on testing history data. 
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